In today's world, many software applications (e.g., programs) are constructed so that such applications may be portable from systems and/or machines to other systems and/or machines and may run (e.g., execute) on such systems and/or machines independent of their source (e.g., developers). For example, many software providers, such as Microsoft®, develop software applications (e.g., Word®) that may be purchased from these providers and installed on individual systems and/or machines for use.
Typically, these software applications include source code that is organized in several modules that are linked to form an executable program. In addition, these software applications may include resource data that is utilized by the software applications during runtime. As a result, the development of these software applications generally requires generation of several different file types that cooperate to provide the functionality of a particular software application.
A popular method utilized in a Windows® environment is a combination of modules such as dynamic-link library (DLL) files, resource files, library files, and other file types that are used to generate a software application. As a result, in particular instances, a software application may depend on a large number of files to handle different functionality during the course of execution. Typically, these files are compiled individually and linked during the “development” stage to form the application. That is, in many instances, these files are compiled to generate binaries that are integrated into the application and the shipped software application is an integrated package of a number of different compiled binary files.
With respect to DLL files, when an application uses a routine in a particular DLL file, the operating system of the system or machine the application is installed on loads the DLL file into memory, resolves references to the functions available in the particular DLL file so that they can be called by the application, and unloads the DLL file once the functions are no longer needed by the application. Thus, individual DLL files are only loaded as needed and do not tie up resources when they are not needed. Such a configuration is commonly referred to as dynamic linking.
While DLL files are typically composed of executable code (e.g., functions), in many instances, data is also embedded in DLL files for use by the application. For instance, many applications make use of data, such as graphics, parameters, bitmaps, icons, strings, and the like for rendering of graphical elements on a screen. Although such data may be provided in independent forms such as external files or databases, many times such data is packaged (e.g., embedded) into a DLL for ease of providing the data along with the application (e.g., deployment) and/or for security so that a user of the application cannot easily alter, replace, or corrupt the data.
In some instances, such data may need to be modified or expanded. For example, an application is typically developed with a default language. For instance, an application may be developed with a default language of English in a United States locale. However, if the application is being marketed to a country with a different language than the default language for the application, say French, the text and appearance of the controls used on various user interfaces may need to be modified to reflect the new language. For example, the controls for Microsoft® Word® would need to be changed from English to French before the application can be readily sold in French speaking areas.
In many instances, the data for these controls are embedded in a default resource (e.g., DLL) and the typical method for providing the data for these controls in French is to have the developer provide a satellite resource (e.g., satellite DLL) specifically for French that may be utilized by the application at runtime instead of the default resource. This can be a time-consuming process and can lead to frustrated potential customers who may wish to purchase the application in their native language. Thus, a need in the art exists to be able to extract embedded resources from a DLL, edit those resources, and re-compile the DLL with the edited resources without having to involve the developer. It is with respect to this consideration and others that the disclosure herein is presented.